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ABSTRACT 



Improved key management is provided by a public key 
replacement apparatus and method for operating over inse- 
cure networks. An active public key and the mask of a 
replacement public key are provided by a key server to 
nodes where the active key is used to encrypt and verify 
messages. To replace the active public key with the replace- 
ment public key, a key replacement message is sent to the 
node. The key replacement message contains the replace- 
ment public key and contains the mask of the next replace- 
ment key. The mask of the replacement public key may be 
generated by hashing or encrypting. The key replacement 
message is signed by the active public key and the replace- 
ment public key. Nodes are implemented by a computer, a 
smart card, a stored data card in combination with a publicly 
accessible node machine, or other apparatus for sending 
and/or receiving messages. In a particular application, a 
financial transaction network, nodes are consumer nodes, 
merchant nodes, or both, and transactions are securely sent 
over a possible insecure network 

13 Claims, 7 Drawing Sheets 
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KEY REPLACEMENT IN A PUBLIC KEY 
CRYPTOSYSTEM 

This application is a division of 08/605,427 Feb. 22, 
1996 now U.S. Pat. No. 5,761,306. s 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has no objection to the xerographic to 
reproduction by anyone of the patent document or the patent 
disclosure in exactly the form it appears in the Patent and 
Trademark Office patent file or records, but otherwise 
reserves all copyrights whatsoever. 

1. Field of the Invention 15 
The present invention relates to the field of secure trans- 
action processing, more specifically to the field of public key 
encryption of transaction data. 

2. Background Art 

A cryptographic system is a system for sending a message 20 
from a sender to a receiver over a medium so that the 
message is "secure", that is, so that only the intended 
receiver can recover the message. A cryptographic system 
converts a message, referred to as "plaintext" into an 
encrypted format, known as "ciphertext." The encryption is 2 5 
accomplished by manipulating or transforming the message 
using a "cipher key" or keys. The receiver "decrypts" the 
message, that is, converts it from ciphertext to plaintext, by 
reversing the manipulation or transformation process using 
the cipher key or keys. So long as only the sender and 
receiver have knowledge of the cipher key, such an 
encrypted transmission is secure. 

A "classical" cryptosystem is a cryptosystem in which the 
enciphering information can be used to determine the deci- 
phering information. To provide security, a classical cryp- 
tosystem requires that the enciphering key be kept secret and 35 
provided to users of the system over secure channels. Secure 
channels, such as secret couriers, secure telephone transmis- 
sion lines, or the like, are often impractical and expensive, 

A system that eliminates the difficulties of exchanging a 
secure enciphering key is known as "public key encryption/' 40 
U.S. Pat. No. 4,405,829 and Diffie and Hellman, "New 
Directioas in Cryptography," IEEE Trans, Inform. Theory, 
vol. IT- 22, pp. 644654, November 1976, teach public key 
encryption. With public key encryption, two keys are used, 
a private key and a public key. The keys are symmetrical, 45 
i.e., either key can be the public key or the private key — the 
labels "public" and "private" simply identify which key is 
made available to the public, and which key is kept private 
by the "owner" of the key pair. Public key encryption is 
applied to a "message". A message is text, graphics, data, or 50 
other digitized information, and public key encryption is 
used to either encrypt the message making it unreadable by 
anyone unless they have the private key or to create a 
readable message with a digital signature. A digital signature 
is created for a specific message using the private key. Only 
a person with knowledge of the private key is able to create 
a valid digital signature for a given message, so this prevents 
others from generating or altering messages and creating 
forged signatures. 

To keep a message to the key owner private, the sender of 
the message will obtain the recipient's public key and use 60 
that key to encrypt the message. Before encryption, the 
message is said to be a "plain text" message (although the 
message might not be text at all) and following encryption, 
the message is said to be a "cipher text" message. The cipher 
text message can only be converted back to the original plain 65 
text message by a decryptor knowing the recipient's private 
key (the other key in the recipient's key pair). Of course, 



with enough computing power and a poorly chosen encryp- 
tion scheme or key pair, a decryptor might be able to extract 
the plain text message without knowing the key. It is 
assumed here that a robust encryption scheme is selected 
such that the private key is indeed required, 

A message is digitally "signed" by the key owner by 
applying a key and the message to a digital authenticator, 
which outputs a digital signature to be attached to the 
message. The recipient of the message can then apply the 
message, the digital signature and the key used to generate 
the signature to an authenticator which will indicate whether 
or not the digital signature was generated from that exact 
message and the key. With public key signatures, the private 
key is used to generate the digital signature and the public 
key is used to verify the signature. 

In a transaction processing system, such as with the use of 
smart cards or terminals, a transaction is formed into a 
message and encrypted using the secret key of the operator 
of the transaction processing system. The term "smart card" 
refers to a card such as a bank card which contains data 
storage and computing ability, as opposed to a more con- 
ventional card, which contains only data storage, typically in 
the form of data stored on a magnetic stripe. A terminal 
might be an automatic teller machine (ATM), a terminal in 
a bank, a home personal computer, or other means for a user 
to send and receive data. 

U.S. Pat. No. 4,972,472 issued to Brown et al. shows a 
method and apparatus for changing a master key in a 
cryptographic system. That system provides storage loca- 
tions for three keys: a pending key, an active key and a 
retired key, When a key is to be replaced, the new key is 
stored in pending key location When a key update command 
is given, the existing active key is shifted to the retired key 
location and the pending key is shifted into the active key 
location. The retired key is used for applications which have 
not yet been made aware of the key change. Over time, 
applications are made aware of the change and shift over 
from using the retired key to using the active key. 

One disadvantage of the Brown et al. system is that a 
replacement key could be sent by someone with unautho- 
rized access to the channel used to transmit the keys. Thus, 
the key replacement apparatus is only useful where the 
channel in which the replacement keys are sent out is secure. 

As should be apparent, anyone knowing the key owner's 
secret key can pose as the key owner, read the key owner's 
messages and create or alter messages sent in the name of 
the key owner. In an insecure system, unauthorized persons 
have the ability to view the traffic between the key server 
and the key users, whether or not such eavesdroppers know 
the secret keys being used. Once a secret key is 
compromised, it can no longer serve its purposes of making 
messages private. 

One problem with a distributed system of smart cards or 
terminals is that they are widely distributed and when a 
secret key is compromised, it is impractical for all the 
holders of the smart cards or users of terminals to return to 
the central key authority to exchange keys or otherwise 
establish a clear channel to transmit the replacement key. 

Another problem is the rapid and continual increase in 
computing power available. The impending obsolescence of 
DES (Data Encryption Standard — a secret key algorithm) is 
in part due to the subsequent developments in computing. At 
one time, a noted cryptologist calculated that a message 
encoded with DES could be decrypted without knowing the 
secret key in a month using $20 million in computer 
hardware. Recently, a group of noted cryptographers esti- 
mated that a S10 million investment in hardware would 
recover a DES key in 6 minutes (see "Minimal Key Lengths 
for Symmetric Ciphers to Provide Adequate Commercial 
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Security" Blaze et al., A Report by an Ad Hoc Group of 
Cryptographers and Computer Scientists, January 1996, 
published at http://www.bsa. org/bsa/cryptologist. html). 
Thus, what is needed is a capability to increase security of 
keys as large amounts of raw computing power becomes 5 
more accessible to potential attackers. 

SUMMARY OF THE INVENTION 

Improved key management is provided by virtue of the 
present invention. The present invention provides an active 10 
public key and a "masked" replacement public key to nodes 
of a network. Herein "masked" or "the mask of" refers to 
any manner of securing the replacement key so that it is 
computationally difficult to determine the replacement key 
from its masked version. In one embodiment of the inven- 15 
tion the masking of the replacement key is accomplished by 
hashing the replacement public key. An active public key 
and the hash of the replacement public key are provided by 
a key server to nodes of the network. Each time a key 
replacement is performed, the active public key is discarded, 2Q 
the replacement public key replaces the active public key, 
and the next replacement public key replaces the replace- 
ment public key. Thus, two public keys are recognizable at 
a node at any one time. These keys are network-wide keys 
and are used in addition to any node-specific key pairs. 

Each node includes a system for sending and receiving 25 
messages to and from the network, such as a networked 
personal computer, a smart card, or a data card combined 
with a public terminal. Initially, each node is provided with 
the active public key and the hash of the replacement public 
key, along with any default node "owned" key pairs. The 30 
network -wide public keys have corresponding private keys 
which are owned by the operator of the network. The initial 
keying of the node is done over a secure channel between the 
node and the network operator. While other secure channels 
are possible, the simplest method is for the network operator 35 
to maintain control over some element of the node during the 
process of installing the initial public key information. 

A node uses the active public key (the network active 
public key) to encrypt or sign messages destined for the key 
server or a third party. When the active private key has been 40 
compromised or is at risk of calculation, the key server sends 
out a key replacement message containing the replacement 
key and the hash of its own replacement key, replaces the 
active private key from the replacement private key storage 
and places the next replacement private key into the replace- 45 
ment private key storage. As should be apparent, according 
to this chain of succession, each new key (public or private) 
is first a next replacement key, then a replacement key, then 
an active key, then finally it is discarded. At the node, the 
active public key is replaced with the replacement public 
key and the hash of the replacement public key is replaced 
with the hash of the next replacement public key. 

The key replacement message is signed by the active 
private key and the replacement private key. Because the 
message is signed by the replacement private key, it could 
ordinarily come from an entity with knowledge of the 55 
replacement private key before the message was sent. 

If brute force computation of the active public/private key 
pair becomes feasible, that pair is deemed compromised, and 
the key replacement process is performed. Because only the 
hash of the replacement public key is available to an 60 
attacker, increasing computing power does not weaken the 
replacement public key as fast as the active public key, since 
many more operations are needed to determine the replace- 
ment public key and to then compute the replacement public 
key. Thus, supplying only the hash of the replacement public 65 
key until it is needed at the active public key helps ensure 
that the replacement key cannot be computationally deter- 
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mined with the same order of magnitude of computing 
power required to computationally determine the active 
public key. 

In an alternate embodiment of the invention, the replace- 
ment public key is encrypted instead of using the hash of the 
replacement public key. When the active private key has 
been compromised or is at risk of calculation, the key server 
sends out a key replacement message containing the replace- 
ment key and the encrypted next replacement key, replaces 
the active private key from the replacement private key 
storage and places the encrypted next replacement private 
key into the replacement private key storage. The key 
replacement message also contains the key for decrypting 
the replacement public key and the message is signed by the 
active private key and the replacement private key. Because 
the message is signed by the replacement private key, it 
could only come from an entity with knowledge of the 
replacement private key before the message was sent. The 
decryption used on the encrypted next replacement key need 
not be the same as that used on the encrypted replacement 
key. 

In a specific embodiment, multiple nodes of an insecure 
network are defined by the interconnected computers 
(personal computers, workstations, etc.) configured with the 
ability to send messages from one node to another or from 
one node to many nodes. At each node, memory is main- 
tained with the active public key, the mask of the replace- 
ment public key, and the node's specific private/public key 
pair. Typically, a node is associated with one user, such as an 
individual using the node to send messages to other users at 
other nodes. For example, a node could be a personal 
computer connected to the Internet and the messages could 
be financial transactions transmitted by the user to banks 
and/or merchants. 

In an alternate specific embodiment, the key user uses a 
smart card to store the active public key and the mask of the 
replacement public key, the key server is a financial insti- 
tution and the message sent between the key user and the key 
server are financial transactions. In yet another embodiment, 
user specific data is stored on a card held by the user and the 
card is inserted or read by a publicly available terminal to 
form the node system. 

In other embodiments, a node maintains multiple sets of 
active and masks of replacement public keys, one from each 
of a plurality of master nodes. This allows for independent 
secure communications with different master nodes. 

A further understanding of the nature and advantages of 
the inventions herein may be realized by reference to the 
remaining portions of the specifications and the attached 
drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a network in which the 
present invention is used; 

FIG. 2 is a flow chart of a process of replacing a key in 
a secure manner; 

FIG. 3 is a block diagram of a specific application wherein 
the network is used to carry secure traffic between consum- 
ers and merchants; 

FIG. 4 is a schematic diagram of a portion of a key 
replacement message; 

FIG. 5 is a block diagram of a network in which an 
alternate embodiment of the present invention is used; 

FIG. 6 is a flow chart of a process of replacing a key in 
a secure manner in an alternate embodiment of the inven- 
tion; and 

FIG. 7 is a schematic diagram of a portion of a key 
replacement message in an alternate embodiment of the 
invention 
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DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

A system for key replacement in a public key cryptogra- 
phy system is described. In the following description numer- 
ous specific details, such as key length, encryption 
algorithm, etc., are set forth in detail in order to provide a 
more thorough description of the present invention. It will be 
apparent, however, to one skilled in the art, that the present 
invention may be practiced without these specific details. In 
other instances, well known features have not been 
described in detail so as not to unnecessarily obscure the 
present invention. 

FIG. 1 is a block diagram of a network 10 which connects 
two nodes 12 (user node 1 and user node 2) to each other and 
to a key server 16. Although only two nodes are shown for 
clarity, it should be apparent that many more nodes are 
possible. As should also be apparent, network 10 need not be 
actually insecure, but is assumed to be so. An insecure 
network is a network where the possibility exists that an 
eavesdropper 18 is listening to network traffic. 

Each node L2 is shown coupled to its own data key 
storage 20. User node 1 is shown with a message block 22 
containing a message intended for delivery over network 10 
to user node 2. Data key storage 20 contains storage for the 
active public key, a masked version of the replacement 
public key (here the hash of the replacement public key) and 
the user node's private/public key pair. Typically, the nodes 
are associated with individuals and organizations who are 
network users and operate and control their respective 
nodes, to send messages as desired, read received messages, 
change the user node key pair and publish the user node 
public key. 

In the present invention, the hash of the replacement 
public key may be generated using any of several well 
known algorithms such as the MD5 algorithm or the SHA 1 
algorithm or any other suitable hashing algorithm. 

The following notation is used herein: "A" refers to the 
active key pair, with "Apu" being the active public key and 
"Apr" being the active private key. Likewise, the replace- 
ment key pair is "R", with "Rpu" being the replacement 
public key and "Rpr" being the replacement private key. The 
hash of a message M using a key K is written as H(M). 

The user key pair is denoted by "U", with the public and 
private keys being "Upu" and "Upr" respectively. Auser key 
pair is distinguished from the active key pair and the 
replacement key pair in that the latter two pairs are used 
system wide, while a user key pair is generated and main- 
tained by the user of a specific node. 

Often, to ensure that the contents of a message have not 
been altered and to verify the node from which a message 
was sent, the message is "digitally signed". To digitally sign 
a message, a node generates a digital signature block from 
the message contents and the node's private key as is known 
in the art. The digital signature block is then attached to the 
message. Because of the way the digital signature block is 
generated, it would be extremely difficult to determine a 
digital signature block for a message without knowing the 
private key used, and the digital signature blocks for the 
original message and an altered version of that message are 
unlikely to be the same. In a digital signature system, the 
recipient can apply the message, the digital signature block 
and the sender's public key to a signature verifier. The 
signature verifier reports whether or not that message was 
the exact message used to generate the digital signature. 
Herein, a message with a digital signature is denoted as (M) 
[K], where M is the message and [K] is the digital signature 
generated for message M using key K. 

In the example described below, only one master node is 
used and the operator of that node controls key server 16 and 

\ 
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thus controls, or "owns", the active public/private key pair 
and the replacement public/private key pair. Thus, the opera- 
tor of key server 16 knows, and keeps secret, the active 
private key and the replacement private key. In some 
5 systems, the active and replacement key pairs are referred to 
as "system key pairs" to distinguish them from user key 
pairs. 

In FIG. 1, key server 16 is shown coupled to a key server 
public key database 24 for holding the public keys of each 

10 participating node. Key server 16 is also shown coupled to 
receive "replace key" commands from a central public key 
controller 26, which is in turn coupled to storage 28 for the 
active private key (Apr) and storage 30 for the replacement 
private key (Rpr). Key server 16 sends messages, such as 
message 40 and key replacement message 42 to nodes 12 
over network 10. In a preferred embodiment, storage 28 and 
storage 30 are not located in the same physical location or 
secured by a common security method, so that a single 
breach of security which allows access to one key will not 
allow access to the other key. 

20 It is assumed that eavesdropper 18 has the capability to 
send messages which appear to be sent by a node other than 
itself, such as node 12 or key server 16. With this capability, 
eavesdropper 18 might send a key replacement message to 
user node 1 falsely indicating that the message was sent by 

25 key server 16. This forged message would instruct user node 
1 to update Apu to a value provided (apparently) by key 
server 16. If eavesdropper 18 sends a false Apu value which 
is paired with a private key known to eavesdropper 18, and 
if user node 1 accepts the message as authentic and changes 

3 0 Apu, eavesdropper 18 will be able to decrypt all subsequent 
messages encrypted with the false Apu. Eavesdropper 18 
could also send key server 16 a message apparently from 
user node 1 where the message indicates that user node 1 has 
changed its user public key, Ulpu, to a public key which is 

35 paired with a private key known by eavesdropper 18. If 
accepted by key server 16, eavesdropper 18 would then be 
able to decrypt any messages from key server 16 which are 
encrypted with Ulpu. 

En operation, of course, user nodes 12 and key server 16 
are more cautious. To securely send a message from one 

40 node to another, the sender must obtain the recipient's real 
public key and use that key to encrypt the message. To know 
the real key for the recipient, the sender must have some way 
of assuring that the public key for the recipient is correct The 
public keys for specific nodes are obtained by querying key 

45 server 16, which supplies the public keys from node key 
database 24. These public keys are the keys published by the 
user nodes. 

Since network 10 is deemed insecure, it is assumed that 
if user node 1 requests a public key from user node 2, 

50 eavesdropper 18 could stand in place of user node 2, 
intercept the request, reply with a key known to eavesdrop- 
per 18, intercept the message and decrypt the message. To 
prevent this scenario, the user nodes supply their public keys 
to key server 16 using a message which could not have been 

55 sent from eavesdropper 18 and which is not readable by 
eavesdropper 18. To do this, key server 16 needs to engage 
in one initial secure interaction with each node, to get the 
node's public key and be assured that it was sent from that 
node. Fortunately, this is easily done during the set-up of a 
node. For example, if the node is a personal computer, a 

60 distribution diskette could contain an initial user key pair or 
the key pair could be distributed over the telephone. If each 
message from a node to key server 16 is digitally signed with 
the node's private key, key server 16 is assured that it was 
not sent by eavesdropper 18. If the message is also encrypted 

65 with the active public key, eavesdropper 18 cannot read the 
message. If one user compromises the private key of its 
node, the security breach is confined to that user's node and 
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is easily remedied by sending a new key over a secure command to key server 16, where the key replacement 

channel to that node (e.g., sending a new smart card to the command includes the replacement public key and the hash 

user of the node). However, if the active public key is of the public key from the next replacement key pair, and 5) 

compromised, without more, each node in the entire system the next replacement public key is inserted into message 42 

would have to be reinitialized with the replacement public 5 a s field H(Rlpu). Thus example is for the first generation of 

key over secure channels. The secure channel is not needed key replacement, in the second generation, the field is 

with the present invention where only the active key is designated H(R2pu), to be consistent with the conventions 

compromised, whether it be by authorized access to storage used here. Because the keys are paired, these steps must be 

28 or by computational brute force. done together, otherwise messages might be encrypted with 

Key server 16 accepts key replacement commands from one generation of keys and decryption would be attempted 

central public key controller 26, which decides when to with a different generation of keys, 

replace the active public key, Apu. Central public key The fie]d Rpu comains the rep i a cement key 

controller 26 generates a new replacement key pair each -ru a fiJ j rr /D1 x t , , , /. , 

time the active key is to be replaced with the existing ™ 6 * 6e««ted by tasfong the next 

replacement key, and updates storage 28 and 30 accordingly S^Z? C^UT&T^ * l Z\?* mba 6* 

Herein the new key pair is referred to as (Rlp U> Rlpr), and 15 hadimg function HO- The hashing of Rlpu can be 

subsequently generated new pairs are (R2pu, W), (Mpu. eUher by Cenlral P ublic ^ comroller 26 ° f ke V 

R3pr), etc. The process of secure replacement of the public _ „ T _ /A , . „,„, n . . . 

key over an insecure network is shown in FIG. 2. fields SIG ( A P r ) and SIG(Rpr) are digital signatures, 

FIG. 2 is a flow chart of a process for publishing a public ^ ™ m *™™ l ? c ™*J?" [ , Apr] and ^respectively, 

key and for replacing a public key when its paired private 20 ^ dl f al S,G ( A P r > 15 ^signature of message 42 

key is compromised or insufficiently secure. In the example USing * e f ive pnvate ke * \ e > contents of 

shown, the public key being replaced is Apu, the active S ! ora f 28 bef ° re * e ^p acement B done. This digital 

public key of key server 16. The active publickey might not signature is verified by applying message 42 and the other 

be actually compromised, as key replacement might be « paired Wlth i hc S i? ni °S key Apr, namely active 

called for as technology advances to the point where it is 25 ^ ke ? Apu ' 10 a ' S ! milar1 ^ the dl S lta > sl S na,u L re 

conceivable that Apu could be calculated by brute force, in SI ° (Rpr) f V f; ified by D app1 ^ * me ^ e 42 and the 

which case the replacement key would be a longer or more rc P lacement P ubhc ^ R P U > «° the verifier, 

complex key. Alternatively, key replacement could occur on If both dl & ltal signatures venfy message 42, the node 

a regular, periodic basis, since a secure channel Ls not replaces H(Rpu) with H(Rlpu) and replaces Apu with Rpu. 

needed. The process of key replacement must occur both at In thls the active P ublic ke V stored in stora S e 20 is 

key server 16 and at nodes 12, since keys are paired. Thus, 30 re P laced Wlth the replacement public key, which was also 

when the private key is replaced in storage 28, that replaced stored in stora g e 20 > and lhe hash of the next replacement 

key cannot be used unless the public key stored in data public key extracted from message 42 is stored in storage 20 

storage 20 is also replaced. as lne nasn of the replacement public key. 

Referring again to FIG. 2, the steps of the process shown Referring again to FIG. 2, in step S4, the digital signature 

there are labeled SI, S2, S3, etc., for ease of reference. In 35 t A P r ] is ver ifled using Apu, If the digital signature does not 

step SI, Apu and H(Rpu) are supplied initially to each node match the message and the active public key (Apu), then the 

over a secure channel. As explained above, this step need ke y replacement message is ignored (S5). In some 

only be done once. The key replacement process begins with embodiments, the node will send a message to key server 16 

step S2, where a new key pair (Rlpu, Rlpr) is generated). t0 tne effect lhal an unauthorized key replacement message 

This is done by either key server 16 or central public key *o nas apparently been sent. 

controller 26. In step S3, key server 16 sends a key replace- If the digital signature [Apr] is verified, the replacement 

ment message (such as key replacement message 42 shown public key, Rpu, is extracted from the key replacement 

in FIG. 1 and in detail in FIG. 4) to each node 12, or message (S6) 

broadcasts a single key replacement message. A number of The replacement public key, Rpu, is used to verify the 

fields of key replacement message 42 are shown in FIG. 4, 45 digital signature [Rpr] of the key replacement message (S7). 

These fields include the replacement public key 150, the If the digital signature [Rpr] does not verify, the process 

hash of the next replacement public key 152, and digital flows to step S5, otherwise it continues to step S8. In step S8, 

signatures for the message 154, 156. the node replaces Apu in storage 20 with the replacement 

The entire key replacement message is digitally signed by public key, Rpu and replaces H(Rpu) in storage 20 with the 

both the active private key, Apr, and the private replacement 50 hash of the next replacement public key, H(Rlpu) (S9). 

key, Rpr. Additionally, the message might be encrypted At this point, key replacement is complete. If desired, the 

using the active public key, Apu. However, given that Apu process can be repeated (S10) so that yet another new key 

might have been compromised, a more secure method is to pair (R2pu, R2pr) is generated, where R2pu becomes the 

send separate messages to each node, each encrypted with replacement key with Rlpu being the active key. Performing 

the node's public key. If the key replacement message is the process twice is useful where both the active key and the 

encrypted, it is decrypted by the node. replacement key are nearing obsolescence. If the replace - 

FIG. 4 shows key replacement message 42 in greater ment key is never generally available, i.e., only its hash is 

detail. This message 42 is sent from key server 16 to node generally available, any computation to break the keys will 

12 as part of the key replacement process. The fields shown take longer to break the replacement key than the active key, 

are Rpr, H(Rlpu), SIG (Apr) and SIG(Rpr). since the replacement public key must be broken before the 

The key replacement process has the following steps: 1) 60 replacement private key can be attacked, 

a new key pair is generated by central public key controller If the replacement private key is physically compromised, 

26, 2) central public key controller 26 moves the existing but the active private key is not, this method will still 

replacement private key from storage 30 to storage 28, securely transmit the key replacement message over the 

making it the new active private key, 3) cenlral public key insecure network, since it is signed by the active private key. 

controller 26 moves the next replacement private key to 65 Of course, in this situation, the key replacement would be 

storage 30, making it the new replacement private key, 4) done twice in quick succession, in order to retire the 

central public key controller 26 sends a key replacement compromised replacement key. 
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In an alternate embodiment, the masking of the replace- The key replacement process has the following steps: 1) 

ment public key can be accomplished by encrypting il. FIG. a new key pair is generated by central public key controller 

5 illustrates a system similar to the sysiem in FIG. 1. Like 26, 2) central public key controller 26 moves the existing 

elements have been given like numerals in FIGS. 1 and 5. replacement private key from storage 30 to storage 28, 

One difference in FIG. 5 is that in data key storage 20A, the $ ma ki ng it the new active private key, 3) central public key 

encrypted replacement public key is stored instead of the controller 26 moves the next replacement private key to 

hash of the replacement public key. storage 30 maki [{ , he new replacernent private keVj 4) 

The following notation is used in connection with FIG. 5: central public key contro n er 2 6 sends a key replacement 
, re ^ ers 1 ° ^ * ct \yfK e y P air ' W1 . ' Ap u " being the active command to key server 16j where lhe key replacement 
public key and Apr being the active private key. Likewise, coramand includcs thc ncw public key f rom P th e next 
the replacement key pair is R with Rpu bang the 10 lacementk ( d 5) th / nexl replacem ent public key 
replacement public key and Rpr being the replacement • • , . * a** a u r v^m \ -n.- 
private key. Encryption of a message M using a key K is ls ^saage 42 as Held E_Xl(Rlpu) TTns 
written as E_K(M), while decryption of the encrypted exam P le IS for the hr ?» -^neraton of key replacement. In the 
message E_K(M) using key K is written as D_K(E_K second gyration, the field is designated E_X2(R2pu), to 
(M)). This notation refers to both secret key encryption and 1 . be consistent with the conventions used here. Because the 
public key encryption, although when referring only to keys are paired, these steps must be done together, otherwise 
public key encryption, the more specific notation E_Kpu messages might be encrypted with one generation of keys 
(M) and D__Kpr (M) is used to dearly indicate the different and decryption would be attempted with a different genera- 
components of the key or key pairs are used for encryption tion of keys. 

and decryption. The functions E_K() and D_K() need not The field X contains the decryption key for E__X(Rpu), 
be distinct. For example, where encryption is the exclusive 20 tn c encrypted replacement key which resides at the node to 
OR'ing of the message and the key, E_K0 and D„K() are which message 42 Ls sent. The field D_X() contains the 
the same functions. decryption method for E_X(Rpu). In some embodiments, 
FIG. 6 is a flow chart similar to FIG. 2 but showing a D_X() Ls known ahead of time as the user node, so this field 
process using encryption for publishing a public key and for is not needed. This field contains, depending on 
replacing a public key when its paired private key is com- 25 implementation, parameters and/or program instructions for 
promised or insufficiently secure. In FIGS. 2 and 6, like the decoding process. With the X and D_XQ fields, the node 
elements have like numbers. In the example shown, the can decrypt the replacement public key. 
public key being replaced is Apu, the active public key of jfc e fi e i d E_Xl(Rlpu) is generated by encrypting the 
key server 16. The active public key might not be actually next replacement public key, now designated Rlpu, accord- 
compromised, as key replacement might be called for as 3Q ing to tne encryption function E_X10- The encryption of 
technology advances to the point where it is conceivable that Rlpu can be performed either by central public key con- 
Apu could be calculated by brute force, in which case the troller 26 of key server 16. 

replacement key would be a longer or more complex key. ^ fields SIG(A ^ r) and SIG(Rpr) lre digital signatures, 

Alternatively, key replacement could occur on * regular, aIso sometimes re ^ d to ^ [A ^ ^ nd [Rpr]) res £ctively. 

periodic basis, since a secure channel is not needed. Hie ^ „ ... oirv a„A ;.TA- m l„™ A 

r . . , , *s 35 I ne digital signature olut Apr; is a signature oi message 42 

process of key replacement must occur both* key server 16 ^ ^ ^ ke * . ^ of 

and at nodes 12, since keys are paired. Thus, when the ^ 2$ ^ ^ ' laccment 7 fa donc ^ di ital 

private key is replaced in storage 28, that replaced key re ^ verified b { [ m ^ ^ ^ Qther 

cannot be used unless the public key stored in data storage ^ which ^ paired ™ ^ ^ namdy active 

20A is also replaced. blic Rey A tQ a verifier similarly, the digital signature 

Referring again to FIG. 6, the steps of the process shown 40 siG(Rpr) is verified by applying message 42 and the 

there are labeled S1A, S2, S3 A, etc., for case of reference. replacement public key, Rpu, to the verifier. Of course, the 

In step S1A, Apu and E_X(Rpu) are supplied initially to re pi ace ment public key, Rpu, must be decrypted before it 

each node over a secure channel. As explained above, this can bc applicd t0 the verifier. 

step need only be done once. The key replacement process If , . u . , . f A ~ t , . 

begins with step S2, where a new key pair (Rlpu, Rlpr) is 45 'f both c d f ri T "'p fV** \ 

generated. This is done by either key server 16 or central re P' a Sf s E f J ^ i i wlh E_Xl(Rlpu) and replaces Apu 

public key controller 26. In step S3A, key server 16 sends a ™' h R P U - D ,h ' s ac lve P ub lc ^ s £> red '» sl . ora g e 

f , m i ' „ hoi ™i™„™t m , ve!lfT „ 20A is replaced with the replacement public key, which was 

key replacement message (such as key replacement message ^ storage 20A and the reolacement reolacement 

42 shown in FIG. 5 and in detail in FIG. 7) to each node 12, also stored m storage ZUA, and trie replacement replacement 

or broadcasts a single key replacement message, A number 50 P^ hc k ^ extracted from m « a £ 42 is stored m storage 

of fields of key replacement message 42 are shown in FIG. 5 ° 20 * as the t ^emem public key Of course the next 

7. These fields include the next replacement public key replacement public key is encrypted and stored in its 

150A, data necessary to decode the replacement public key encrypted form, until the next generahon when it is needed 

152A, 154A, and digital signatures for the message 156A, as tne actlve P ubUc k ^ 

158A Referring again to FIG. 6, in step S4, the digital signature 

The entire key replacement message is digitally signed by 55 t A P r ] is verified usin 6 A P U " If . the di g iul signature does not 

both the active private key, Apr, and the private replacement match the messa g e and the aclive P ubhc ^y (Apu), then the 

key, Rpr. Additionally, the message might be encrypted kev replacement message is ignored (S5). In some 

using the active public key, Apu. However, given that Apu embodiments, the node will send a message to key server 16 

might have been compromised, a more secure method is to 10 the effecl that an unauthorized key replacement message 

send separate messages to each node, each encrypted with 60 nas apparently been sent. 

the node's public key. If the key replacement message is If the digital signature [Apr] is verified, the replacement 
encrypted, it is decrypted by the node. public key, Rpu, is extracted from the key replacement 
FIG. 7 shows key replacement message 42 in greater message (S6A), using the key and decryption method pro- 
detail. This message 42A is sent from key server 16 to node vided by the key replacement message. 
12 as part of the key replacement process. The fields shown 65 Once the replacement public key, Rpu, Ls decrypted, it can 
are X, D_X(), E_Xl(Rlpu), S1G (Apr) and SIG(Rpr). be used to verify the digital signature [Rpr] of the key 
These fields will be described in further detail below. replacement message (S7A). If the digital signature [Rpr] 
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does no! verify, the process flows to step S5, otherwise it 
continues to step S8. In step S8, the node replaces Apu in 
storage 20A with the replacement public key, Rpu and 
replaces E_X(Rpu) in storage 20A with the encrypted next 
replacement public key, E_Xl(Rlpu) (S9A). $ 

At this point, key replacement is complete. If desired, the 
process can be repeated (S10) so that yet another new key 
pair (R2pu, R2pr) is generated, where R2pu becomes the 
replacement key with Rtpu being the active key. Performing 
the process twice is useful where both the active key and the 
replacement key are nearing obsolescence. If the replace- io 
ment key is only ever generally available in encrypted form, 
any computation to break the keys will take longer to break 
the replacement key than the active key, since the encryption 
on the replacement public key must first be broken before 
the replacement private key can be attacked. J5 

If the replacement private key is physically compromised, 
but the active private key is not, this method will still 
securely transmit the key replacement message over the 
insecure network, since it is signed by the active private key. 
Of course, in this situation, the key replacement would be 
done twice in quick succession, in order to retire the 20 
compromised replacement key. 

FIG. 3 shows a specific application of the key replacement 
system, a financial transaction system 100. Several elements 
of FIG. 1 are shown again in FIG. 3: network 10, eaves- 
dropper 18, node public key database 24, central public key 25 
controller 26, and storage 28 and 30. System 100 is used to 
facilitate a secure transaction, such as a credit or debit card 
transaction between a consumer at a consumer node 102 and 
a merchant at a merchant node 104 via network 10. Con- 
sumer node 102 is implemented as a personal computer, a 30 
smart card, or a publicly accessible terminal. If consumer 
node 102 is a publicly accessible terminal, such as an ATM, 
kiosk or point-of-sale (POS) terminal, data personal to the 
consumer would be stored separately (labeled "personal 
storage 110" in the figure), and would include key storage 
106 similar to key storage 20 shown in FIG. 1 or20Aof FIG. 35 
5 and a financial database 108, each coupled to consumer 
node 102. Key storage 106 coupled to the consumer node 
102 stores the central public keys and the consumer's keys, 
public and private, as well as other consumer specific data. 
Merchant node 104 also is coupled to its own key storage 40 
106, which stores the central public keys and merchant keys. 
If a node 12 is both a consumer and a merchant node, it 
might use the same keys for both buying and selling trans- 
actions. 

A key server 112 is coupled to network 10 and central 45 
public controller 26. Key server 112 serves the same purpose 
as key server 16 of FIG. 1, as well as an additional purpose 
of being an authorization server which uses secure links to 
a financial network to secure authorization and/or funds for 
transactions entered into by a consumer at consumer node r n 
102. 

A transaction is shown in FIG. 3 by paths numbered 1 
through 5. A consumer initiates the transaction. For 
example, a consumer might browse publicly available files 
of offerings of a merchant, such as World Wide Web pages 5$ 
on the Internet and decide to order a product. To pay for the 
product, the consumer sends a secure message to the mer- 
chant. To do this, consumer node 102 sends a public key 
request message to key server 112 (path 1). Key server then 
responds with a public key value message back to consumer 
node 102 indicating the public key for merchant node 104 60 
(path 2). These two messages are sent secured by the 
methods described above. The message lo key server 112 
and its response are encrypted and/or signed using the public 
and private keys of key server 112, so those keys must be 
kept especially secure. 65 

The consumer node 102 then sends the transaction data to 
merchant node 104 in a message encrypted with the public 



key for merchant nod 104 and signed by the private key for 
consumer node 102. For example, the message might say 
"charge item #123, quantity 1, to card number 47##-####- 
####-####, expiration date mm/yy". This message is 
decryptable only by the merchant node, since the merchant 
node private key is required for decryption. Merchant node 
104 uses this information to process the payment over the 
secure financial network. The merchant can verify the sig- 
nature on the transaction using the consumer's public key, 
which can be obtained from key server 112. 

Before submitting the payment over the financial 
network, merchant node 104 can check card authorization 
either through the financial network or through key server 
112 (via path 4), which would then check for authorization 
and secure funds. Key server 112 then (path 5) securely 
reports the results of the authorization to consumer node 102 
as well as merchant node 104. 

As should be apparent, the above -described method and 
apparatus might also be used to perform bill payment or the 
secure network might be entirely replaced by network 10, in 
which case issuer banks (who issue credit, debit or bank 
cards to consumers), acquirer banks (who acquire transac- 
tions from merchants), and settlement systems could be 
nodes on network 10. Bill payment might be performed as 
taught by U.S. Pat. No. 5,465,206 (Appl. Sen No.: 08/146, 
515), issued to Hilt, et al. on Nov. 7, 1995, and commonly 
owned with the present application. That patent is incorpo- 
rated by reference herein. 

In summary, the above detailed description has described 
a method and apparatus for securely distributing keys over 
an insecure network from a central source, to allow secure 
communications between nodes and a key server and from 
nodes to nodes, evr,n where each node has no means to 
verify the identity of any other node except the key server. 
The keys that are distributed are the network public keys. 

The above description is illustrative and not restrictive. 
Many variations of the invention will become apparent to 
those of skill in the art upon review of this disclosure. 
Merely by way of example, the apparatus might be imple- 
mented wholly in general purpose computers suitably pro- 
grammed or could be implemented by special purpose 
hardware or integrated circuitry. Also, the above description 
shows the application of key replacement to the public key 
of a network, i.e., the master node's public key. However, 
the same key replacement methods and apparatus could also 
be used for more secure replacement of user node keys. In 
such a system, the key server would maintain user public 
keys and replacement user public keys. 

The scope of the invention should, therefore, be deter- 
mined not with reference to the above description, but 
instead should be determined with reference to the appended 
claims along with their full scope of equivalents. 

What is claimed is: 

1. A public key cryptography apparatus for secure com- 
munications over an untrusted network between a key server 
node and a user node, comprising: 

user data storage, coupled to the user node of the 
untrusted network, for storing a first active public key 
and a first replacement public key; 

key server data storage, coupled to the key server node, 
for storing a first active private key and a first replace- 
ment private key, wherein the first active private key 
and the first active public key are a first key pair and the 
first replacement private key and the first replacement 
public key are a first replacement key pair; 

means for transmitting a key replacement message from 
the key server node to the user node, the key replace- 
ment message comprising the first replacement public 
key, a mask of a second replacement public key and a 



02/17/2004, EAST Version: 1.4.1 



US 6,240,187 Bl 



13 



14 



digital signature proving knowledge by the key server 
node of both of the first active private key and the first 
replacement private key; and 
means for using the second replacement public key to 
replace the first replacement public key and using the 5 
first replacement public key as a second active public 
key wherein the second active public key is used to 
encrypt or decrypt data in conjunction with a corre- - 
sponding second active private key, 

2. The public key cryptography apparatus of claim 1 10 
wherein the mask of the first replacement public key is a 
hash of the first replacement public key. 

3. The public key cryptograph apparatus of claim 2 
wherein the hash is generated using the MD5 hashing 
algorithm. 15 

4. The public key cryptography apparatus of claim 2 
wherein the hash is generated using the SHA 1 hashing 
algorithm. 

5. The public key cryptography apparatus of claim 1 
wherein the mask of the first replacement public key is 20 
generated by encrypting the first replacement public key. 

6. A key replacement system comprising: 

plurality of user nodes, each coupled to send and receive 
messages over said network, each said user node hav- 
ing a user node storage device for storing at least an 25 
active public key, an indication of a replacement public 
key, and a user node key pair; 

a key server, coupled to send and receive messages over 
a network, said key server coupled to at least a first 
storage device for storing user node public key in for- 30 
mation for said plurality of user nodes coupled to said 
network; 

a key controller, coupled to said key server, including a 
key controller storage device for storing an active 
privale key and a replacement private key, said active 35 
public key and said active private key comprising a key 
pair, said replacement public key and said replacement 
private key comprising a replacement key pair; 

said key controller producing a key replacement message 
including said replacement public key, an indication of 40 
a next replacement public key, a first digital signature 
verifiable by said active public key, and a second digital 
signature verifiable by said replacement private key; 

wherein said key replacement message is forwarded to 
said plurality of user nodes; 

wherein the authenticity of said first digital signature and 
second digital signature are verified before the plurality 
of user nodes replace said active public key with said 
replacement public key, thereby defining a new active 
public key; and 



45 



wherein the new active public key is used to encrypt or 
decrypt data sent over said network. 

7. The key replacement system of claim 6, wherein said 
indication of said replacement public key is a mask of said 
replacement public key. 

8. The key replacement system of claim 6, wherein said 
indication of said replacement public key is an encrypted 
version of said replacement public key. 

9. The key replacement system of claim 7, wherein said 
mask of said replacement public key is generated by said key 
server. 

10. The key replacement system of claim 7, wherein said 
mask of said replacement public key is generated by said key 
controller, 

11. The key replacement system of claim 6, wherein said 
key server and said key controller are implemented on a 
common computer system. 

L2. A public key cryptography apparatus for secure com- 
munications over a network, comprising: 
user data storage, coupled to a user node of said network, 

for storing an active public key and a replacement 

public key; 

key server data storage, coupled to a key server node of 
said network, for storing an active private key and a 
replacement private key, wherein said active private 
key and said active public key are an active key pair 
and said replacement private key and said replacement 
public key are a replacement key pair; 
said key server node transmitting a key replacement 
message from said key server node to said user node 
over said network, said key replacement message com- 
prising said replacement public key, a mask of a next 
replacement public key and a digital signature proving 
knowledge by said key server node of both of said 
active private key and said replacement private key; 
said user node receiving said key replacement message 
and replacing said active public key with said replace- 
ment public key if the authenticity of said digital 
signature is verified, wherein said replacement public 
key and replacement private key are used to encode 
data according to the Public Key Infrastructure for 
secure communications over a network. 
13. The apparatus of claim 12, further comprising a 
plurality of user nodes coupled to said network, each of said 
user nodes receiving said key replacement message and 
replacing said active public key with said replacement 
public key if the authenticity of said digital signature is 
verified. 
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